• chore(rivetkit): remove inline tests #4668
• fix(guard): serialize gateway actor keys correctly #4655
• fix(api): subscribe before namespace workflow dispatch #4654
• fix(rivetkit): restore hibernatable sockets and hydrate serverless starts #4658
• fix(rivetkit-native): expose full hibernation metadata to JS #4657 👈 (View in Graphite)
• fix(pegboard): persist and replay hibernating requests #4656
• fix(rivetkit): keep internal error exposure behavior consistent #4661
• test(rivetkit): stabilize actor db driver tests #4664
• fix(test): stabilize lifecycle, sleep, queue, and run edge cases #4660 : 1 other dependent PR (#4665 )
• test(rivetkit): re-enable gateway URL and direct-registry coverage #4659
• fix(rivetkit): add lifecycle error retry and gateway HTTP routing #4666
• chore(engine): publish engine bases in ci #4649 : 2 other dependent PRs (#4650 , #4652 )
• chore: lockfile lefthook #4647
• fix(rivetkit): surface native sqlite kv errors to callers #4645
• fix(rivetkit): prevent sleep races during disconnect and db work #4644
• fix(rivetkit): isolate engine envoys and propagate startup failures #4643
• test(rivetkit): remove wasm sqlite-only fixtures and coverage #4642
• chore(sqlite-vfs): remove wasm sqlite packages and workspace wiring #4641
• chore(rivetkit): remove wasm sqlite runtime #4614
• fix(sqlite-native): restore native startup kv preload #4639
• fix(sqlite-native): delete metadata before chunk range #4638
• fix(sqlite-native): keep truncate cache coherent #4637
• fix(sqlite-vfs): use delete range for truncate cleanup #4636
• fix(sqlite-native): restore kv error hook #4635
• perf(sqlite-native): avoid cloning cached read chunks #4634
• perf(sqlite-native): gate kv operation labels #4633
• perf(sqlite-native): reuse read cache for partial writes #4632
• perf(sqlite-native): remove delete file existence probe #4631
• fix(sqlite-native): gate native read cache behind env var #4630
• fix(pegboard): isolate runner config dc lookup failures #4625 : 1 other dependent PR (#4626 )
• docs(pegboard): note runner config upsert split write risk #4624
• fix(pegboard): unpack global runner config keys correctly #4623
• fix(pegboard-gateway): enforce tunnel message state #4622
• fix(pegboard-runner): clear terminal tunnel routes #4621
• fix(pegboard): skip protocol version keys in runner pool backfill #4620
• fix(pegboard): create missing normal runner configs #4619
• fix(epoxy): reuse cached optimistic value #4618
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

PR Review: fix(rivetkit-native): expose full hibernation metadata to JS

Overview

This PR does two related things:

1. Forwards the previously zeroed-out envoyMessageIndex, rivetMessageIndex, path, and headers fields from JS hibernation restore entries into the native HibernatingWebSocketMetadata struct.
2. Implements the can_hibernate callback, which was previously a stub returning false. It now calls a JS canHibernate handler synchronously using block_in_place + a std::sync::Mutex-backed response map.

The first change is straightforward and correct. The second is more complex and has some concerns.

Issues

Critical: Indefinite block when JS does not call respondCallback

can_hibernate blocks on rx.blocking_recv() with no timeout. In the JS handler, respondCallback is only called if handle._raw is truthy:

async (canHibernate) => {
    if (handle._raw) {  // if null, Rust blocks forever
        await handle._raw.respondCallback(...);
    }
},

If handle._raw is null at call time (e.g. handle being torn down), the Rust thread blocks indefinitely and stalls the envoy thread pool. A timeout on the rx side (e.g. tokio::time::timeout) would make this safe.

Potential memory leak when response is never sent

tx is inserted into response_map and only removed by respondCallback via map.remove(&response_id). If respondCallback is never called (the if handle._raw guard makes this possible), the entry leaks indefinitely. The Rust side should clean up the map entry after blocking_recv returns, regardless of outcome.

ThreadsafeFunctionCallMode::Blocking vs NonBlocking

All other event_cb.call sites use NonBlocking. The new can_hibernate uses Blocking, which will stall the calling thread if the TSFN queue is full. Given that can_hibernate already blocks on block_in_place this is tolerable, but the difference from every other call site is worth a comment explaining the intent.

Minor Issues

unwrap_or_else(HashMap::new) should be unwrap_or_default() (envoy_handle.rs)

error field in JS response is silently ignored by Rust. The error path sends { canHibernate: false, error: String(err) } but Rust only reads canHibernate. Consider a tracing::warn! on the Rust side for the error case.

URL construction assumes path starts with /. new Request(\http://actor${event.path}\`, ...)produceshttp://actorfoo` if path is empty or lacks a leading slash. A fallback like event.path || '/' would be safer.

What looks good

• The std::sync::Mutex switch for ResponseMap is correct. can_hibernate is synchronous so tokio::sync::Mutex cannot be used there. All async callbacks hold the lock only briefly before dropping it, never across .await points.
• block_in_place is the correct primitive for blocking inside a Tokio multi-thread runtime.
• Forwarding actual metadata fields instead of hardcoded zeros/empty strings is clearly the right fix.
• TypeScript types in index.d.ts correctly reflect the new fields (number for u16, optional Record<string,string> for Option<HashMap<String,String>>).
• The ?? 0 / ?? "" / ?? {} defaults in wrapper.js are consistent with unwrap_or_default() on the Rust side.